Windows: Remove use of deprecated function SHGetFolderPath and use SHGetKnownFolderPath instead #5862
Conversation
kit-ty-kate
force-pushed
the
windows-SHGetKnownFolderPath
branch
from
6ae1db9 to
78ba932
Compare
kit-ty-kate
force-pushed
the
windows-SHGetKnownFolderPath
branch
from
78ba932 to
c7f1059
Compare
There was a problem hiding this comment.
Thanks for this - apart from getting rid of youthfully exuberent (= daft) comments of mine from the source code, the fact SHGetKnownFolderPath handles allocation itself will automatically deal with long paths (which wasn't a thing when I wrote the original code; I just still harboured an unhealthy desire to keep old OSes working...!). I have a hunch that long paths might be what's gone wrong in the original issue (although it's surprising).
My instinct would be to have a single C stub taking a variant (more closely wrapping one API function), but actually I think your instinct is better in having separate functions! 🙂
We need to link opam with ole32 (for CoTaskMemFree) and uuid (for the FOLDERID_ "constants") - I'm pushing a commit which hopefully does that bit!
kit-ty-kate
force-pushed
the
windows-SHGetKnownFolderPath
branch
5 times, most recently
from
c3d8903 to
8d630a6
Compare
…GetKnownFolderPath instead Co-authored-by: David Allsopp <david.allsopp@metastack.com>
Co-authored-by: David Allsopp <david.allsopp@metastack.com>
kit-ty-kate
force-pushed
the
windows-SHGetKnownFolderPath
branch
from
8d630a6 to
032e409
Compare
Fixes #5861Based on the 6 years old comment at the top of
OPAMW_SHGetFolderPathwe might probably want to use the new API and don't want to spend the time supporting such an old system